Day 8 我們已經把首頁做成比較像任務管理工具的樣子。
目前畫面上有：
不過這些都還只是靜態畫面。
接下來如果真的開始做功能，就不能只跟 Claude Code 說：
幫我做新增任務。
因為這句話其實有很多地方沒有講清楚。
例如：
如果我沒有說，Claude Code 就只能自己猜。
所以今天先不加功能，先看看需求講得模糊和講得清楚，差別會有多大。
假設我直接跟 Claude Code 說：
幫我加入新增任務功能。
這句看起來很正常，但其實資訊很少。
Claude Code 可能會自己決定：
新增表單
新增 POST route
建立 task model
接資料庫
新增完成後 redirect
這些做法不一定有問題。
但問題是：
那是它自己補的，不一定是我現在想做的。
我可以先不讓它改檔案，而是問：
先不要修改任何檔案。
如果我只跟你說：
「幫我加入新增任務功能」
請告訴我這個需求裡有哪些地方不夠明確，
以及你會需要我補充哪些資訊。
這時 Claude Code 通常會反問：
表單放在哪裡？
需要哪些欄位？
資料要存在哪裡？
要不要現在接 MySQL？
這些問題其實就是我自己應該先想清楚的東西。
同樣是新增任務，我可以改成：
今天只做「新增任務」的第一版功能。
需求如下：
1. 點擊首頁的「新增任務」按鈕後，
進入新的表單頁面
2. 表單包含：
- 任務名稱
- 說明
- 狀態
- 分類
- 截止日期
3. 今天先完成畫面和 Flask route
4. 先不要接 MySQL
5. 表單送出後暫時不用真的儲存資料
6. 不要加入修改、刪除或其他功能
請先告訴我：
- 需要新增哪些檔案
- 需要修改哪些檔案
- 每個修改的原因
如果有不清楚的地方先問我，
不要自行擴大功能範圍。
先規劃，不要直接修改。
這樣 Claude Code 就比較知道今天到底要做到哪裡。
做到現在，我發現新功能開始前，至少要說清楚三件事情。
例如：
目前首頁已經完成靜態 UI，
還沒有接資料庫，也沒有真正的 CRUD 功能。
這樣 Claude Code 不用自己猜目前專案狀態。
例如：
今天只做新增任務表單。
這句可以避免它一次把整套 CRUD 都做掉。
例如：
目前先不要：
- 接 MySQL
- 做修改功能
- 做刪除功能
- 加入 AJAX
- 加入 Claude API
這一段我覺得滿有用。
Claude Code 有時候不是做太少，而是做太多。
需求寫清楚，不代表每次都要寫一大篇。
像：
把首頁標題改成 My Task Manager。
這種小修改就不用列十幾條規則。
但如果是：
加入新增任務功能。
因為會牽涉到頁面、route、表單，甚至資料庫，這時候就值得多講一點。
我目前的判斷很簡單：
如果有很多地方可以讓 Claude Code 自己猜，我就多補一些限制。
另一個我開始注意的地方是，不要一次塞太多功能。
例如：
幫我做新增、修改、刪除、分類、狀態、MySQL、
AI、測試和 UI。
這樣 Claude Code 很可能一次改很多檔案。
就算最後真的能跑，我自己也很難檢查它到底做了什麼。
所以目前我比較想維持：
做一個功能
↓
自己看懂
↓
實際測試
↓
再做下一個
之後如果是比較大的功能，我大概會照這個格式：
目前狀態：
[現在專案做到哪裡]
今天目標：
[今天只要完成什麼]
需求：
- ...
- ...
- ...
目前不要做：
- ...
- ...
- ...
請先告訴我：
1. 需要新增哪些檔案
2. 需要修改哪些檔案
3. 每個修改的原因
如果需求有不清楚的地方，
先問我，不要自行擴大功能範圍。
先規劃，不要直接修改。
這不是固定格式。
只是現在用起來比較不容易讓 Claude Code 跑太遠。
Day 9 沒有新增檔案，也沒有修改首頁。
今天主要是在整理一件事情：
怎麼把需求講清楚。
如果需求太模糊，後面花最多時間的可能不是寫程式，而是一直叫它重改。
現在首頁已經有：
+ 新增任務
但目前按下去還沒有任何功能。
Day 10 就拿今天整理的方式，真的給 Claude Code 一份比較清楚的需求。
iThome鐵人賽
看影片追技術